Traditionally, hardware drivers are packaged as separate binary components that extend the Operating System (OS), the hardware drivers also provide Application Programming Interfaces (APIs) to applications for controlling devices associated with the drivers. This separation between the OS components and the application components (API) adds complexity to updates requiring either:                the OS to be enhanced with a driver packaged into the OS and thereby forcing an OS update when a driver needs to be changed; or        the driver needs to be deployed as a separate deployment unit installed as a separate package after the OS, this separate package requires special OS permissions to be deployed and, therefore, introducing the potential for security vulnerabilities and attacks.        
The issues, associated with hardware device installation, are particularly noticeable with Self-Service Terminals (SSTs), such as Automated Teller Machines (ATMs). An ATM is a highly secure type of SST, where administrative access to the underlying OS, hardware devices, and software is restricted to select engineers. Remote network access is generally forbidden, even to the servicing engineers. As a result, when a new hardware device is swapped out of the ATM (for a defective device or when a new device with newer features is installed on the ATM) the bank staff has to wait for an available engineer and the update process can take some time. Moreover, the OS itself may not even permit the newer device or may require an update to the OS, which can also add significant time and complexity to the installation and testing of a new device on the ATM platform.